Use the '--app-version' parameter to 'helm package' to dynamically
set the chart 'appVersion' field. We can then omit the hardcoded
'appVersion' field in the Chart.yaml file.
The chart 'version' field is also set by 'helm package' but we still
need to define it in the Chart.yaml file since 'help dep update'
requires it. The placeholder 'version' field is now set to 0.0.0 just
to give it some value.
For E2E, since the version fields are no longer hardcoded, it now
simulates a release by running 'helm package' and extracting the tar
files to HELM_REPO_LOCATION, now set to ./helm_repo.
Signed-off-by: Tom Pantelis <tompantelis@gmail.com>
There's no mention in the upstream helm docs about this file nor is
there any docs about interactive user prompting at all (that I can see).
Nor do we document any mechanism for user prompting. It would seem this
is an obsolete remnant from an earlier version of helm so let's remove
it. This also eliminates hard-coded image versions that need to be
updated.
Signed-off-by: Tom Pantelis <tompantelis@gmail.com>
...from the top shield banner. I don't see any reason why we
need that. This eliminate places we need to update when we release a
new chart version. The other places where it references a version is
in the sample values. I changed those to just 0.14.0 but we don't
really need to update these as they're intended to be examples.
Signed-off-by: Tom Pantelis <tompantelis@gmail.com>
The issue reporting step of the Markdown broken link check GitHub Action
is failing due to missing permissions.
> Error: Resource not accessible by integration
Signed-off-by: Daniel Farrell <dfarrell@redhat.com>
Due to a bug in LH which was fixed in devel, but not yet backported, we
have to preload the LH images to get latest versions (and operator due
to a similar reason).
Signed-off-by: Mike Kolesnik <mkolesni@redhat.com>
When releasing, since the job pushes to the git repository, it needs
to have write permission on "contents".
Signed-off-by: Stephen Kitt <skitt@redhat.com>
The release frequency of some GHAs means we end up with daily
dependabot PRs, which results in lots of not-particularly-useful
review work. Reducing the update cadence to weekly shouldn't expose us
to much risk and will reduce PR churn.
Signed-off-by: Stephen Kitt <skitt@redhat.com>
Set the GitHub Actions token permission to null in most workflows.
This results in:
GITHUB_TOKEN Permissions
Metadata: read
The default permissions, used without the null override, are either
GITHUB_TOKEN Permissions
Actions: write
Checks: write
Contents: write
Deployments: write
Discussions: write
Issues: write
Metadata: read
Packages: write
Pages: write
PullRequests: write
RepositoryProjects: write
SecurityEvents: write
Statuses: write
or
GITHUB_TOKEN Permissions
Actions: read
Checks: read
Contents: read
Deployments: read
Discussions: read
Issues: read
Metadata: read
Packages: read
Pages: read
PullRequests: read
RepositoryProjects: read
SecurityEvents: read
Statuses: read
Jobs triggered by PRs get read permissions, other jobs get write.
One job requires non-null permissions to function.
The dependent issues GHA needs PR/issues write permissions to add/remove
`dependent` labels. It needs status write permission to block/unblock
PRs when dependencies are missing/met. Fails with HttpError otherwise.
Signed-off-by: Daniel Farrell <dfarrell@redhat.com>
If you haven't done so yet, please label a node as `submariner.io/gateway=true` to elect it for running Submariner.
{{- end }}
By default, Submariner runs with 1 replica. If you have more than one Gateway host, you can scale Submariner to N replicas, and the other Submariner pods will simply join the leader election pool.
By default, Submariner runs with 1 replica. If you have more than one Gateway host, you can scale Submariner to N replicas, and the other Submariner pods will simply join the leader election pool.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
