Ann on start #3
Open
Ann on start #3
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- Replaced the hardcoded list of usernames in the E2E workflow trigger - Triggered E2E tests for pull requests from authors with OWNER, MEMBER, or COLLABORATOR association - Simplified maintenance by automatically allowing trusted contributors to run E2E tests Signed-off-by: Chmouel Boudjnah <[email protected]>
This commit introduces the ability to customize Repository custom resource
names when auto-configuring new GitHub repositories using configurable
templates with placeholder variables.
Changes:
• Add `auto-configure-repo-repository-template` configuration setting
• Support `{{repo_owner}}` and `{{repo_name}}` template variables
• Implement template processing in repository auto-configuration flow
• Add comprehensive documentation with examples
Configuration:
The new `auto-configure-repo-repository-template` setting allows users to
define custom naming patterns for automatically created Repository CRs.
Supported template variables:
- `{{repo_owner}}`: GitHub repository owner/organization name
- `{{repo_name}}`: GitHub repository name
Examples:
- Template: `{{repo_owner}}-{{repo_name}}-repo-cr`
- Repository: `https://github.com/acme/webapp`
- Generated CR name: `acme-webapp-repo-cr`
Backward compatibility:
If no template is specified, the system falls back to the existing default
format: `{{repo_name}}-repo-cr`
This enhancement provides organizations with flexible naming conventions
that can align with their existing Kubernetes resource management practices
while maintaining the convenience of automatic repository setup.
Signed-off-by: Zaki Shaikh <[email protected]>
- Modified the e2e workflow to include contributors - Ensured contributor pull requests trigger tests Signed-off-by: Chmouel Boudjnah <[email protected]>
The use of the state label (which is mutable) for deciding when to report to the SCM that the PLR was started is flaky. It was seen that the reconciler get events about PLRs with unexpected value for the state label. For example, after the status is reported to the SCM, and the label value is patched to "started", after serval reconcile iterations the label had the "queued" value again. This can happen because of unsafe patching done by controllers (not just the PAC controllers) which reconciles PLRs. Introduce a new annotation for indicating the the status was reported to the SCM. By adding an annotation which is set once, we remove the risk that its value will get overwritten by other controllers (since maps are merged when patched, values are not getting removed unless explicitly defined in the patch - https://datatracker.ietf.org/doc/html/rfc7386#section-2) In addition, at the start of each reconcile loop, ensure that we operate on the latest version of the PLR and not using a stale value from the cache. Assisted-By: Cursor Signed-off-by: Gal Ben Haim <[email protected]>
Set the state annotation and labels in pipelineascode only after the state was reported to the SCM. This is achieved by patching the PLR with the state label/annotation after it was created. This change is needed in order to avoid a case where the watcher will report a status before PAC. With this change the issue can't happen, since the watcher only reconciles PLRs that has the state annotation, so the first reconcile of the PLRs will happen only after PAC already sent the initial status to the SCM. In addition, simplify the condition which checks if the "queued" state annotation/label should be set. We can only check if the PLR is pending, it doesn't matter if the reason is because of PAC's concurrency control or an external controller. Signed-off-by: Gal Ben Haim <[email protected]>
Instead of running the reconcile loop on the fresh pipeline, skip it and let the next iterations to reconcile it. Signed-off-by: Gal Ben Haim <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
📝 Description of the Change
🔗 Linked GitHub Issue
Fixes #
👨🏻 Linked Jira
🚀 Type of Change
fix:)feat:)feat!:,fix!:)docs:)chore:)refactor:)enhance:)deps:)🧪 Testing Strategy
✅ Submitter Checklist
fix:,feat:) matches the "Type of Change" I selected above.make testandmake lintlocally to check for and fix anyissues. For an efficient workflow, I have considered installing
pre-commit and running
pre-commit installtoautomate these checks.