repositories: fix keys and archs by SMillerDev · Pull Request #548 · saltstack-formulas/salt-formula

SMillerDev · 2023-05-19T09:59:36Z

PR progress checklist (to be filled in by reviewers)

Changes to documentation are appropriate (or tick if not required)
Changes to tests are appropriate (or tick if not required)
Reviews completed

What type of PR is this?

Primary type

[build] Changes related to the build system
[chore] Changes to the build process or auxiliary tools and libraries such as documentation generation
[ci] Changes to the continuous integration configuration
[feat] A new feature
[fix] A bug fix
[perf] A code change that improves performance
[refactor] A code change that neither fixes a bug nor adds a feature
[revert] A change used to revert a previous commit
[style] Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc.)

Secondary type

[docs] Documentation changes
[test] Adding missing or correcting existing tests

Does this PR introduce a `BREAKING CHANGE`?

No.

Related issues and/or pull requests

#545
#539

Describe the changes you're proposing

Move to onedir packages by default
Set the OS architecture in debian based repos

Pillar / config required to test the proposed changes

Debug log showing how the proposed changes work

Documentation checklist

Updated the README (e.g. Available states).
Updated pillar.example.

Testing checklist

Included in Kitchen (i.e. under state_top).
Covered by new/existing tests (e.g. InSpec, Serverspec, etc.).
Updated the relevant test pillar.

Additional context

lmf-mx · 2023-06-12T22:58:25Z

@SMillerDev This does actually break existing deployments and should be noted.

It doesn't cover Ubuntu 22.04 on 3005 onedir, which uses https://repo.saltproject.io/salt/py3/ubuntu/22.04/amd64/3005/salt-archive-keyring.gpg.
It also doesn't cover older releases that don't support onedir.

That said, I don't think it's the wrong direction, but there's some things still amiss.

IMO, everything should go to onedir or better yet, default to it with a pillar override, before new versions that don't support the classic packages are released.
Specifically in the Ubuntu mapping, key_url points to a place that doesn't exist for 22.04, since it doesn't include the onedir "salt/" dir in the path.

jeff350 · 2023-06-14T01:12:35Z

@SMillerDev It was clarified in a salt issue that the -2023 on the key is the year the key was generated. So this PR should go to 2023 being hard coded instead of the jinja to get the current year.

saltstack/salt#64144 (comment)

SMillerDev · 2023-06-14T10:52:50Z

Thanks for the heads up, I'll fix that.

jeff350

I think there are a few more small changes to fix the urls of repos.

Could you please look at this and modify your commit messages to follow the format that will pass the commitlint in CI. you can see this here https://gitlab.com/saltstack-formulas/salt-formula/-/jobs/4471523712#L125

jeff350 · 2023-06-16T01:51:53Z

-  pkgrepo: 'deb [signed-by=/usr/share/keyrings/salt-archive-keyring.gpg arch=amd64] {{ salt_repo }}/{{ py_ver_repr or 'apt' }}/{{ os_lower }}/{{ osrelease }}/amd64/{{ salt_release }} {{ oscodename }} main'
-  pkgrepo_keyring: '{{ salt_repo }}/{{ py_ver_repr or 'apt' }}/{{ os_lower }}/{{ osrelease }}/amd64/{{ salt_release }}/salt-archive-keyring.gpg'
+  pkgrepo: 'deb [signed-by=/usr/share/keyrings/SALT-PROJECT-GPG-PUBKEY-2023.gpg arch={{ repoarch }}] {{ salt_repo }}/{{ py_ver_repr or 'apt' }}/{{ os_lower }}/{{ osrelease }}/{{ repoarch }}/{{ salt_release }} {{ oscodename }} main'
+  pkgrepo_keyring: '{{ salt_repo }}/{% if oscodename == "jammy" %}salt/{% endif %}{{ py_ver_repr or 'apt' }}/{{ os_lower }}/{{ osrelease }}/amd64/{{ salt_release }}/SALT-PROJECT-GPG-PUBKEY-2023.gpg'


i think this can be modified to support more versions. This would limit 3006 not being installed on 18.04 and 20.04. Would we want an if loop here based off of salt version being installed?

If we keep logic of oscodenames + salt versions, it adds a lot of uneeded temporary complexity because we need to apply this logic also for key naming.
I think that poeople relying on old repository can pin version of this formula to 1.x.x while waiting to update their salt ecosystem.
Proposed a PR here -> #561

lmf-mx · 2023-06-21T16:07:38Z

I think there are a few more small changes to fix the urls of repos.

Could you please look at this and modify your commit messages to follow the format that will pass the commitlint in CI. you can see this here https://gitlab.com/saltstack-formulas/salt-formula/-/jobs/4471523712#L125

@SMillerDev Can you update the commit messages to pass the linter?

SMillerDev · 2023-06-21T19:26:33Z

I will once I actually get it to work

lmf-mx · 2023-06-21T19:36:18Z

I will once I actually get it to work

If you mean the formula, I believe I've covered all the cases in the update based on your PR, #550
If you mean the messages, you can interactive rebase and force push, https://docs.github.com/en/pull-requests/committing-changes-to-your-project/creating-and-editing-commits/changing-a-commit-message

techhat · 2023-09-27T20:30:24Z

FYI, SALTSTACK-GPG-KEY.pub no longer exists in the repo, so without some of these changes I'm finding that the most recent release of this formula is now unusable in multiple OSs. @Ch3LL

sticky-note

Please @jeff350, can you take a look here pls #561

sticky-note · 2024-02-01T07:52:07Z

-  pkgrepo: 'deb [signed-by=/usr/share/keyrings/salt-archive-keyring.gpg arch=amd64] {{ salt_repo }}/{{ py_ver_repr or 'apt' }}/{{ os_lower }}/{{ osrelease }}/amd64/{{ salt_release }} {{ oscodename }} main'
-  pkgrepo_keyring: '{{ salt_repo }}/{{ py_ver_repr or 'apt' }}/{{ os_lower }}/{{ osrelease }}/amd64/{{ salt_release }}/salt-archive-keyring.gpg'
+  pkgrepo: 'deb [signed-by=/usr/share/keyrings/SALT-PROJECT-GPG-PUBKEY-2023.gpg arch={{ repoarch }}] {{ salt_repo }}/{{ py_ver_repr or 'apt' }}/{{ os_lower }}/{{ osrelease }}/{{ repoarch }}/{{ salt_release }} {{ oscodename }} main'
+  pkgrepo_keyring: '{{ salt_repo }}/{% if oscodename == "jammy" %}salt/{% endif %}{{ py_ver_repr or 'apt' }}/{{ os_lower }}/{{ osrelease }}/amd64/{{ salt_release }}/SALT-PROJECT-GPG-PUBKEY-2023.gpg'


If we keep logic of oscodenames + salt versions, it adds a lot of uneeded temporary complexity because we need to apply this logic also for key naming.
I think that poeople relying on old repository can pin version of this formula to 1.x.x while waiting to update their salt ecosystem.
Proposed a PR here -> #561

SMillerDev requested a review from a team as a code owner May 19, 2023 09:59

SMillerDev force-pushed the repo_fixes branch from ac5427c to e3a1d92 Compare May 19, 2023 10:03

repositories: fix keys and archs

5958690

SMillerDev force-pushed the repo_fixes branch from e3a1d92 to 5958690 Compare May 19, 2023 11:49

SMillerDev commented Jun 14, 2023

View reviewed changes

Comment thread salt/osfamilymap.yaml Outdated

Comment thread salt/osfingermap.yaml Outdated

Comment thread salt/osmap.yaml Outdated

Comment thread salt/osmap.yaml Outdated

Comment thread salt/osmap.yaml Outdated

Fix key names

5fd67ea

jeff350 requested changes Jun 16, 2023

View reviewed changes

lmf-mx mentioned this pull request Jun 16, 2023

Pr548 updated #550

Closed

19 tasks

lmf-mx mentioned this pull request Jul 26, 2023

fix(repo, maps): fix keys,paths for onedir,classic #551

Closed

19 tasks

sticky-note mentioned this pull request Feb 1, 2024

fix(repos): fix namings after salt binaries and keys move #561

Closed

19 tasks

sticky-note reviewed Feb 1, 2024

View reviewed changes

sticky-note requested a review from jeff350 February 1, 2024 07:54

SMillerDev closed this Oct 13, 2025

Conversation

SMillerDev commented May 19, 2023

PR progress checklist (to be filled in by reviewers)

What type of PR is this?

Primary type

Secondary type

Does this PR introduce a BREAKING CHANGE?

Related issues and/or pull requests

Describe the changes you're proposing

Pillar / config required to test the proposed changes

Debug log showing how the proposed changes work

Documentation checklist

Testing checklist

Additional context

Uh oh!

lmf-mx commented Jun 12, 2023

Uh oh!

jeff350 commented Jun 14, 2023

Uh oh!

SMillerDev commented Jun 14, 2023

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jeff350 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jeff350 Jun 16, 2023

Choose a reason for hiding this comment

Uh oh!

sticky-note Feb 1, 2024

Choose a reason for hiding this comment

Uh oh!

Uh oh!

lmf-mx commented Jun 21, 2023

Uh oh!

SMillerDev commented Jun 21, 2023

Uh oh!

lmf-mx commented Jun 21, 2023

Uh oh!

techhat commented Sep 27, 2023

Uh oh!

sticky-note left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

sticky-note Feb 1, 2024

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Does this PR introduce a `BREAKING CHANGE`?